Many multi-computer data transfer systems used today employ packet-switched networks and use communications protocols included in the Internet Protocol (IP) suite. Particulars of definitions of a number of communication protocols are controlled by the Internet Engineering Task Force (IETF) in a series of Request for Comments (RFC) documents. For example, aspects of the Internet protocol suite are defined in RFC 1122 and RFC 1123.
The protocols most used on the Internet today include the Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP) which, while a number of alternatives exist, are widely carried via the IP suite. TCP provides a number of functions not provided by UDP. For example, TCP can be used to ensure that data packets are submitted by a source node at a rate supported by the intermediate network and destination network node, or that data packets can be transmitted to a destination node and reassembled in an intended sequence. UDP does not provide the sequencing or flow control of TCP. To identify network nodes, IP uses IP addresses. IP version 4 (IPv4) encodes network addresses in 32 bit long binary numbers providing approximately four billion addresses.
Due to demand for connectivity, previously isolated networks have merged into interconnected networks, for example, the integration of mobile phone networks into the Internet, having greatly enlarged total numbers of network devices and demand to distinguish among them. The limited address space provided by IPv4 and the allotment of predetermined numbers of IPv4 addresses to network operators by regulating authorities, have forced solutions to circumvent limitations due to exhaustion of IPv4 address space.
One solution is to transition the Internet to IP version 6 (IPv6), which provides a vastly increased 128 bit address space. However, in order to provide its benefits network wide, virtually all network infrastructure is required to support IPv6. To date, not all network infrastructure supports IPv6, and upgrades from IPv4 to IPv6 are still ongoing. Adoption of IPv6 can be costly, has been slow and IPv6 does not provide an imminent solution to the IPv4 address space dilemma.
Another solution is based on Network Address Translation (NAT). NAT employs translation of network addresses of data packets when they transition a NAT device that connects one part of a network with another part of a network. NAT may receive and retransmit data packets after translating or mapping a source or destination network address thereof. NAT can map one or more network addresses belonging to a first set of network addresses into a single IP address belonging to a second set of network addresses, so that outbound data packets exiting the NAT device have the same source address as the NAT device. NAT further uses rules stored in translation tables to reverse map destination addresses of inbound data packets back into the first set of network addresses. Rules are typically generated in response to outbound data packets and only used for a certain time for reverse mapping of inbound data packets. The time-limited nature of these rules may limit usefulness of existing NAT implementations. NAT is typically used to connect network nodes that have private IP addresses to a network using public IP addresses. Private and public IP addresses are defined in RFC 1918. NAT is described in a number of documents, for example, RFC 2663 and RFC 3022.
Extensions have been developed that recoup interconnectivity functions lost due to NAT but which are otherwise available in many NAT-free network connections. These extensions typically concern connecting small numbers of network nodes to the Internet. Further extensions have been developed in an attempt to enable NAT to connect networks that allow large numbers of network nodes with private IP addresses to connect to the Internet and provide a minimum of interconnectivity functions for them. Known extensions are described in U.S. Pat. Nos. 7,139,828 and 7,362,760. Further documentation referring to or describing various aspects of NAT include the Internet Gateway Device (IGD), Simple Service Discovery Protocol (SSDP), Universal Plug and Play (UPnP), Devices Profile for Web Services (DPWS), NAT-Port Mapping Protocol (NAT-PMP), Zero Configuration Networking (Zeroconf) and Jini™, for example. Existing forms of NAT, however, can be complex, cumbersome and error-prone, and extensions typically fail to provide required scalability or even rudimentary security features.
In addition, current port forwarding methods typically have several limitations. Firstly, address scalability is typically poor because a port forward rule takes away the ability of the NAT to use the port for all IP Source (SRC) addresses. This only allows 65K routable paths per available IPv4 address assuming all the port numbers are used but typically only a small fraction of the port numbers are used because the terminals all want to listen to the same ports. Secondly, port scalability is also typically poor, because the automatic methods used to set up a port forwarding rule require the terminal to request the incoming port and if that port is already used by another terminal, the request is rejected. The terminal could then try another port. If the NAT was busy, this trial and error approach could be long and inefficient. Thirdly, routing security is typically poor as the NAT will route all traffic from any server to the terminal thus creating a possible security risk. Even if narrow port forwarding is used (where only specific IP SRC addresses are being forwarded) there is typically no trust relationship built between the server, the NAT, and the terminal. Fourthly, malware security is typically poor as automated port forwarding protocols, such as UPnP, aren't secure because any malware or flash entity can setup a port forwarding rule and once compromised, the terminal can compromise all the other devices inside the firewall.
Specific problems with limited addressability may occur when contacting a terminal in a private network from an application server that itself is outside the private network. For example, polling in machine-to-machine (M2M) applications of terminals in a mobile network operator's (MNO's) network is becoming increasingly common and is expected to increase with the added mass-M2M market. Polling of terminals in M2M applications is often dynamic and asynchronous and mobile networks typically do not provide externally routable IP addresses. Without an externally routable IP address, however, the application server outside an MNO's core network cannot directly contact a terminal within the core network via IP.
A number of solutions to this issue exist but none of them are secure, scalable, or efficient. For example, some MNOs offer routable IPv4 addresses to the terminals as an additional service. Unfortunately, the limited IPv4 address space does not scale to serve the demand for IP addresses of cellular networks. Furthermore, terminals may send keep-alive messages to prevent routes through NAT from being deactivated, which, however, is not scalable, reliable or efficient as the keep-alive messages may consume significant network resources. This option is also not scalable because the network would quickly become overloaded with keep-alive messages if many terminals employed this approach. This option is also not efficient because many M2M terminals send very little data and thus the amount of keep-alive traffic can be higher than the amount of real data sent, and it is not reliable because the length of time a NAT will keep a route open can be dynamic thus periodic transmission of keep-alive messages may not always keep the route open.
In a further solution, a route to a desired terminal in a private network may be established or reactivated by sending a text message from outside to the terminal so that the terminal may seek proper action to activate the route, which however, causes communication delays and requires the terminal to be addressable by a mobile subscriber integrated services digital network number (MSISDN) which in turn requires special configuration and additional interconnections for the server, which is not cost effective given the expense associated with sending text messages.
Therefore there is a need for a solution that at least overcomes one of the deficiencies of the known art.
This background information is provided to reveal information believed by the applicant to be of possible relevance to the present invention. No admission is necessarily intended, nor should be construed, that any of the preceding information constitutes prior art against the present invention.